---
title: "02-Embedding 模型与文本切块"
created: 2026-08-31
tags:
  - 项目筑基
---

# Embedding 模型与文本切块

> 向量检索系统的效果上限，其实在**进数据库之前**就决定了：embedding 模型选得对不对、文档切得好不好。这一篇整理模型选型与切块策略——同样是"书上看的 + 梳理"，等我实际调过再补体感。

## Embedding 模型在干什么

一句话：**把任意长度的文本压成一个定长向量，语义近的向量距离近**。

- 模型结构大多是 Transformer 编码器（双塔/bi-encoder 思路）：输入文本 → 输出 768 / 1024 / 1536 维向量
- 训练目标就是"拉近相似文本对、推远无关文本对"，所以出来的向量天然带语义
- **query 和文档必须用同一个模型转向量**——不同模型的向量空间互不相通，混用等于拿北京的坐标在上海找路（这是我理解的向量系统第一条铁律）

## 中文模型怎么选（2025 前后的书里信息）

| 模型 | 维度 | 特点 |
| --- | --- | --- |
| **bge 系列**（BAAI 智源） | 1024 | 开源中文标杆，`bge-large-zh-v1.5` 起步即用；`bge-m3` 多语言 + 长文本（8K） |
| gte / text2vec 等开源系 | 768~1024 | 备选，差距不大，跟 MTEB 子榜走 |
| OpenAI text-embedding-3 | 1536 / 3072 | 商用 API，效果稳，数据出境要注意 |
| 国产 API（通义/智谱等） | 1024 量级 | 生态配套方便，合规省心 |

看榜单的方法（书上学到的）：**看 MTEB / C-MTEB 的 Retrieval（检索）子榜，别只看总分**——总分高不代表检索强。

> 💡 bge 有个容易漏的细节：检索时 **query 要加指令前缀**（"为这个句子生成表示以用于检索相关文章："），文档不加——不加前缀召回会掉，这是教程里反复强调的。

## 文本切块：被低估的效果杀手

向量检索查的是"块"（chunk）不是整篇文档，**切块质量直接决定召回质量**。书里的经验结论：

- **块太大**：一个块里混多个主题，向量语义被"平均"稀释，检索命中率降；塞进 prompt 也费 token
- **块太小**：上下文断了，"它支持这个参数"这种指代块成了孤儿，查出来也不知道在说什么
- 常见起点：**中文 200~500 字符一块，相邻块重叠 10%~20%**（overlap 保上下文）

比"固定长度切"更好的做法（按优先级）：

1. **按结构切**：Markdown 标题、段落自然边界——语义天然完整
2. **带锚点切块**：每块前面拼上"所属标题路径"（如 `数据库 > MySQL > 索引`），孤立小块也有上下文
3. **父子块**：用小块做检索（精准），命中后返回它的大父块（完整）——两边都要

> 💡 我的记忆钩子：RAG 效果差先怀疑切块，**十次里有六七次的根因在数据预处理，不在向量库参数**——这是书里出现频率最高的忠告。

## Rerank：便宜又有效的第二级

双塔模型（上面所有 embedding 模型）为了能离线建索引，query 和文档**各自独立**编码，精度有天花板。Rerank 用交叉编码器（cross-encoder）：把 query 和候选文档**拼在一起**过模型，精度高一个档次——代价是每一对都要现场算，没法预建索引。

所以标准姿势是两级流水线：

```
向量检索粗筛 top 50（快，靠 ANN 索引）
    ↓
rerank 精排取 top 5（准，交叉编码器逐对打分）
    ↓
塞进 LLM prompt
```

常用模型：`bge-reranker-large` 等开源重排器。粗筛放宽到 50~100、精排只留 3~5，是书里常见的配比。

---
⬅️ [[01-相似度与向量索引|01-相似度与向量索引]] 🏠 [[00-数据库|00-数据库]] ➡️ [[03-RAG 检索增强生成|03-RAG 检索增强生成]]